Internet Engineering Task Force (IETF) B. Hoeneisen 


Request for Comments: 6118 Ucom.ch 
Updates: 3762, 3764, 3953, 4143, 4002, A. Mayrhofer 
4238, 4355, 4415, 4769, 4969, enum.at 
4979, 5028, 5278, 5333 March 2011 


Category: Standards Track 
ISSN: 2070-1721 


Update of Legacy IANA Registrations of Enumservices 
Abstract 
This document revises all Enumservices that were IANA registered 
under the now obsolete specification of the Enumservice registry 
defined in RFC 3761. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6118. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Hoeneisen & Mayrhofer Standards Track [Page 1] 


RFC 6118 


Update Legacy Enumservice Registrations 


March 2011 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 


10, 2008. 


The person(s) 


controlling the copyright in some of this 


material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 


the copyright in such materials, 
outside the IETF Standards Process, 
not be created outside the IETF Standards Process, 


this document may not be modified 
and derivative works of it may 


except to format 


it for publication as an RFC or to translate it into languages other 
than English. 


Table of Contents 


1. Introduction 4 
2. Terminology 4 
3. IESG Action Bae aves oh e+ A Seas ace Bhd wh A My. AD 
4. Legacy Enumservice Registrations Converted to XML Chunks . . . 5 
4.1. email:mailto 6 
4.2. ems:mailto 7 
4.3. ems:tel 8 
4.4. fax:tel 9 
4.5. ft:ftp 10 
4.6. h323 tn 11 
4.7. ical-access:http 12 
4.8. ical-access:https 13 
4.9. ical-sched:mailto 14 
4.10. ifax:mailto 15 
4.11. im Y TS 16 
4.12. mms:mailto 17 
4.13. mms:tel 19 
4.14. pres 20 
4.15. pstn:sip 21 
4.16. pstn:tel 22 
4.17: sip š 23 
4.18. sms:mailto 24 
4.19. sms:tel . . 25 
4.20. unifmsg:http 26 
4.21. unifmsg:https 27 
4.22. unifmsg:sip 28 
4.23. unifmsg:sips 29 
4.24. vcard rS 30 
4.25. videomsg:http 31 
4.26. videomsg:https 32 
4.27. videomsg:sip 33 
4.28. videomsg:sips 34 
4.29. voice:tel 33 
4.30. voicemsg:http 37 
Hoeneisen & Mayrhofer Standards Track [Page 2] 


RFC 6118 Update Legacy Enumservice Registrations March 2011 


LA NMSLEEMSSHhHEEBS. ara aa as BOR a e O 
32 MOLECEMSGNSIP. des a A A a O 
33: VoOLCEMSGESIDS. e a E e ri A e e el O 
US VO LEEMSD tels wi, £4 a A a ds he ek, Elle ay sis di oA 
SSO, UPIM dap, we. wo) as A Dd A A wn E e A A 
36s -VP LmMe MALLEO A “Sit ae. cee A ee ee a 24S 
STE a A N Fe A alas Pr ee 
poo MODELS te Ak titel A IN a A Se ES de e no 
¿ID AMP E ee ee er ee oe oh een fer eee a de ee 
TANA Considerations o ur u: oe nr Oe Se a ee re a A 
Security Considerations s = aJs ua e... ee «7 
Acknowledgemenes” n ara Ede aa a a a e a A 
> “References e 2 See a aua as a a AAA a (AB 

8.1. Normative References ........... 2... 2... . . 48 

8.2, Informative References... e-e s s e le s ei e rea. 49 
Appendix A. Former Content of the IANA Repository ........ 49 


BRE PRP ss os ds ds A 


oo 0 


Hoeneisen & Mayrhofer Standards Track [Page 3] 


RFC 6118 Update Legacy Enumservice Registrations March 2011 


1. Introduction 


[RFC6117] has obsoleted the IANA registration section of [RFC3761]. 
Since the IANA Enumservice registry contains various Enumservices 
registered under the regime of RFC 3761, those registrations do not 
conform to the new guidelines as specified in [RFC6117]. To ensure 
consistency among all Enumservice registrations at IANA, this 
document adds the (nowadays) missing elements to those legacy 
registrations. Furthermore, all legacy Enumservice registrations are 
converted to the new XML-chunk format, and, where deemed necessary, 
minor editorial corrections are applied. 


However, this document only adds the missing elements to the XML 
chunks as specified in the IANA Considerations section of [RFC6117], 
but it does not complete the (nowadays) missing sections of the 
corresponding Enumservice Specifications. In order to conform with 
the new registration regime as specified in [RFC6117], those 
Enumservice Specifications still have to be revised. 


It is important to note that this document does not update the 
functional specification of the concerned Enumservices. 


The following RFCs are updated by this document: 


[RFC3762] 
[RFC3764] 
[RFC3953] 
[RFC4143] 
[RFC4002] 
[RFC4238] 
[RFC4355] 
[RFC4415] 
[RFC4769] 
[RFC4969] 
[RFC4979] 
[RFC5028] 
[RFC5278] 
[RFC5333] 


00000000000000 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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3. IESG Action 


According to [RFC3761], any Enumservice registration had to be 
published as a Standards Track, Experimental, or BCP (Best Current 
Practice) RFC. [RFC6117] no longer has this requirement, i.e., 
"Specification Required", which implies the use of a Designated 
Expert [RFC5226], is sufficient. 


This document changes the approval requirement for updates to 
Enumservice registrations to Specification Required, whereby the 
specification and request are reviewed by a Designated Expert as 
described in [RFC6117]. 


4. Legacy Enumservice Registrations Converted to XML Chunks 


In the following, the legacy Enumservice Registrations are converted 
to XML chunks that include the new elements introduced by [RFC6117]. 


(Note that references in Sections 4.1 - 4.39 refer to the references 
section within the respective Enumservice Specification.) 


4.1. email:mailto 
<record> 
<!-- email:mailto --> 
<class>Application-Based, Common</class> 
<type>email</type> 


<subtype>mailto</subtype> 
<urischeme>mailto</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource can be 
addressed by the associated URI in order to send an 
email. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4355"/>, Section 6. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
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</requesters> 
</record> 


4.2. ems:mailto 


<record> 
<!-- ems:mailto --> 
<class>Application-Based, Common</class> 
<type>ems</type> 
<subtype>mailto</subtype> 
<urischeme>mailto</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of receiving a message using an email protocol. 
</paragraph> 
<paragraph> 
EMS content is sent over SMTP using the format 
specified by TS 23.140 [15] Section 8.4.4 and TS 
26.140 [16] Section 4, as an MMS message. Within 
such a message, EMS content is carried as either a 
text or application/octet-stream MIME sub-part (see 
TS 26.140 [16], Section 4.1). 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc4355"/>. 
</paragraph> 
</functionalspec> 
<security> 
<paragraph> 
There are no specific security issues with this 
Enumservice. However, the general considerations of 
Section 6 of <xref type="rfc" data="rfc4355"/> apply. 
</paragraph> 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
</record> 
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4.3. ems:tel 


<record> 
<!-- ems:tel --> 
<class>Application-Based, Common</class> 
<type>ems</type> 
<subtype>tel</subtype> 
<urischeme>tel</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of receiving a message using the Enhanced Message 
Service (EMS) [14]. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc4355"/>. 
</paragraph> 
</functionalspec> 
<security> 
<paragraph> 
There are no specific security issues with this 
Enumservice. However, the general considerations of 
Section 6 of <xref type="rfc" data="rfc4355"/> apply. 
</paragraph> 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Note that an indication of EMS can be taken as 
implying that the recipient is capable of receiving 
SMS messages at this address as well. 
</paragraph> 
</additionalinfo> 
</record> 
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4.4. fax:tel 


<record> 
<!-- fax:tel --> 
<class>Application-Based, Subset</class> 
<type>fax</type> 
<subtype>tel</subtype> 
<urischeme>tel</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of being contacted to provide a communication 
session during which facsimile documents can be 
sent. 
</paragraph> 
<paragraph> 
A client selecting this NAPTR will have support 
for generating and sending facsimile documents to 
the recipient using the PSTN session and transfer 
protocols specified in [12] and [13] in 
<xref type="rfc" data="rfc4355"/> - 
in short, they will have a fax program with a local 
or shared PSTN access over which they can send 
faxes. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc4355"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4355"/>, Section 6. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
</record> 
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4.5. ft:ftp 


<record> 
<== SEESEED > 
<class>Application-Based, Subset</class> 
<type>ft</type> 
<subtype>ftp</subtype> 
<urischeme>ftp</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is a file 
service from which a file or file listing can be 
retrieved. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4002"/>, Section 5. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4002"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
</record> 
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4.6. h323 


<record> 
<!-- h323 --> 
<class>Protocol-Based</class> 
<type>h323</type> 
<!-- No subtype --> 
<urischeme>h323</urischeme> 
<functionalspec> 
See <xref type="rfc" data="rfc3762"/>, Section 3. 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc3762"/>, Section 5. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc3762"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Orit_Levin"/> 
</requesters> 
</record> 


Hoeneisen & Mayrhofer Standards Track [Page 10] 


RFC 6118 Update Legacy Enumservice Registrations March 2011 


4.7. ical-access:http 


<record> 
<!-- ical-access:http --> 
<class>Application-Based, Common</class> 
<type>ical-access</type> 
<subtype>http</subtype> 
<urischeme>http</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified 
can be addressed by the associated URI in order to access 
a user's calendar (for example free/busy status) using 
the CalDAV [7] protocol for Internet calendaring. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5333"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5333"/>, Section 4. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5333"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rohan_Mahy"/> 
</requesters> 
</record> 
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4.8. ical-access:https 


<record> 
<!-- ical-access:https --> 
<class>Application-Based, Common</class> 
<type>ical-access</type> 
<subtype>https</subtype> 
<urischeme>https</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified 
can be addressed by the associated URI in order to access 
a user's calendar (for example free/busy status) using 
the CalDAV [7] protocol for Internet calendaring. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5333"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5333"/>, Section 4. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5333"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rohan_Mahy"/> 
</requesters> 
</record> 
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4.9. ical-sched:mailto 
<record> 
<!-- ical-sched:mailto --> 


<class>Application-Based, Common</class> 
<type>ical-sched</type> 
<subtype>mailto</subtype> 
<urischeme>mailto</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified 
can be addressed by the associated URI used for 
scheduling using Internet calendaring via Internet mail 
with the iMIP [6] protocol. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5333"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5333"/>, Section 4. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5333"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rohan_Mahy"/> 
</requesters> 
</record> 
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4.10. ifax:mailto 


<record> 
<!-- ifax:mailto --> 
<class>Application-Based, Subset</class> 
<type>ifax</type> 


<subtype>mailto</subtype> 
<urischeme>mailto</urischeme> 
<functionalspec> 
See <xref type="rfc" data="rfc4143"/>, Section 1. 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4143"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4143"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Kiyoshi_Toyoda"/> 
<xref type="person" data="Dave_Crocker"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
The URI Scheme is 'mailto” because facsimile is a 
profile of standard Internet mail and uses standard 
Internet mail addressing. 
</paragraph> 
</additionalinfo> 
</record> 
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4.11. im 
<record> 
<!-- im --> 
<class>Application-Based, Common</class> 
<type>im</type> 
<!-- No subtype --> 
<urischeme>im</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified is an ’im:’ URI. The ’im:’ URI scheme 
does not identify any particular protocol that will 
be used to handle instant messaging receipt or 
delivery, rather the mechanism in RFC 3861 [4] is 
used to discover whether an IM protocol supported by 
the party querying ENUM is also supported by the 
target resource. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5028"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5028"/>, Section 3. 
</security> 


<usage>COMMON</usage> 

<registrationdocs> 
<xref type="rfc" data="rfc5028"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 

</registrationdocs> 

<requesters> 
<xref type="person" data="Rohan_Mahy"/> 

</requesters> 

</record> 
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mms :mailto 


<record> 
<!-- mms:mailto --> 
<class>Application-Based, Common</class> 
<type>mms</type> 
<subtype>mailto</subtype> 
<urischeme>mailto</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of receiving a message using an email protocol. 
</paragraph> 
<paragraph> 
MMS messages are sent over SMTP using the format 
specified by TS 23.140 [15] Section 8.4.4 and TS 
26.140 [16] Section 4. 
</paragraph> 
<paragraph> 
within and between MMS Environments (MMSE, 
network infrastructures that support the MultiMedia 
Service), other pieces of state data (for example, 
charging-significant information) are exchanged 
between MMS Relay Servers. Thus, although these 
servers use SMTP as the "bearer" for their 
application exchanges, they map their internal state 
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to specialized header fields carried in the SMTP message 


exchanges. The header fields used in such MMSE are 
described in detail in [17]. 

</paragraph> 

<paragraph> 


References are contained in <xref type="rfc" data="rfc4355"/>. 


</paragraph> 
</functionalspec> 
<security> 
<paragraph> 
There are no specific security issues with this 
Enumservice. However, the general considerations of 


Section 6 of <xref type="rfc" data="rfc4355"/> apply. 


</paragraph> 

</security> 

<usage>COMMON</usage> 

<registrationdocs> 
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 

</registrationdocs> 

<requesters> 
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<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
The MMS Architecture describes an interface 
between the MMSE and "legacy messaging systems" 
(labelled as MM3) that accepts "standard" SMTP 
messages. Thus, although the MMS Relay Server that 
supports this interface appears as a standard SMTP 
server from the perspective of an Internet-based 
mail server, it acts as a gateway and translator, 
adding the internal state data that is used within 
and between the MMS Environments. This mechanism is 
described in [17], which also includes references to 
the specifications agreed by those bodies 
responsible for the design of the MMS. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc4355"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.13. mms:tel 


<record> 
<!-- mms:tel --> 
<class>Application-Based, Common</class> 
<type>mms</type> 
<subtype>tel</subtype> 
<urischeme>tel</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of receiving a message using the Multimedia 
Messaging Service (MMS) [15]. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc4355"/>. 
</paragraph> 
</functionalspec> 
<security> 
<paragraph> 
There are no specific security issues with this 
Enumservice. However, the general considerations of 
Section 6 of <xref type="rfc" data="rfc4355"/> apply. 
</paragraph> 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Note that MMS can be used as an alternative to 
deliver an SMS RP-DATA RPDU if, for example, the 
SMS bearer is not supported. If an entry includes 
this Enumservice, then in effect this can be taken 
as implying that the recipient is capable of 
receiving EMS or SMS messages at this address. Such 
choices on the end system design do have two small 
caveats; whilst in practice all terminals supporting 
MMS today support SMS as well, it might not 
necessarily be the case in the future, and there may 
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be tariff differences in using the MMS rather than 
using the SMS or EMS. 
</paragraph> 
</additionalinfo> 
</record> 


4.14. pres 


<record> 
<!-- pres --> 
<class>Application-Based, Common</class> 
<type>pres</type> 
<!-- No subtype --> 
<urischeme>pres</urischeme> 
<functionalspec> 
See <xref type="rfc" data="rfc3953"/>, Section 4. 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc3953"/>, Section 6. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc3953"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jon_Peterson"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
See <xref type="rfc" data="rfc3953"/>, Section 3. 
</paragraph> 
</additionalinfo> 
</record> 
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4.15. pstn:sip 


<record> 
<!-- pstn:sip --> 
<class>Application-Based, Common</class> 
<type>pstn</type> 
<subtype>sip</subtype> 
<urischeme>sip</urischeme> 
<functionalspec> 
<paragraph> 
These Enumservices indicate that the 
resource identified can be addressed by the 
associated URI in order to initiate a 
telecommunication session, which may include two-way 
voice or other communications, to the PSTN. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4769"/>, Section 7. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4769"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Richard_Shockey"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
A Number Portability Dip Indicator (npdi) should 
be used in practice 
(see <xref type="rfc" data="rfc4769"/>, Section 4). 
</paragraph> 
</additionalinfo> 
</record> 
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4.16. pstn:tel 


<record> 
<!-- pstn:tel --> 
<class>Application-Based, Ancillary</class> 
<type>pstn</type> 
<subtype>tel</subtype> 
<urischeme>tel</urischeme> 
<functionalspec> 
<paragraph> 
These Enumservices indicate that the 
resource identified can be addressed by the 
associated URI in order to initiate a 
telecommunication session, which may include two-way 
voice or other communications, to the PSTN. These 
URIs may contain number portability data as 
specified in RFC4694 [10]. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc4769"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4769"/>, Section 7. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4769"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Richard_Shockey"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
A Number Portability Dip Indicator (npdi) should 
be used in practice 
(see <xref type="rfc" data="rfc4769"/>, Section 4). 
</paragraph> 
</additionalinfo> 
</record> 
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4.17. «sip 
<record> 
LS Sip case 
<class>Protocol-Based</class> 
<type>sip</type> 
<!-- No subtype --> 


<urischeme>sip</urischeme> 
<urischeme>sips</urischeme> 
<functionalspec> 


See <xref type="rfc" data="rfc3764"/>, Section 4. 


</functionalspec> 
<security> 


See <xref type="rfc" data="rfc3764"/>, Section 6. 


</security> 
<usage>COMMON</usage> 
<registrationdocs> 


March 2011 


<xref type="rfc" data="rfc3764"/> (updated by RFC 6118) 


<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 

<xref type="person" data="Jon_Peterson"/> 
</requesters> 
<additionalinfo> 

<paragraph> 


See <xref type="rfc" data="rfc3764"/>, Section 3. 


</paragraph> 
</additionalinfo> 
</record> 
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4.18. sms:mailto 
<record> 
<!-- sms:mailto --> 
<class>Application-Based, Common</class> 
<type>sms</type> 


<subtype>mailto</subtype> 
<urischeme>mailto</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of receiving a message using an email protocol. 
</paragraph> 
<paragraph> 
SMS content is sent over SMTP using the format 


specified by TS 23.140 [15] Section 8.4.4 and TS 
26.140 [16] Section 4, as an MMS message. Within 
such a message, SMS content is carried as either a 


text or application/octet-stream MIME sub-part 
TS 26.140 [16], Section 4.1) 

</paragraph> 

<paragraph> 


March 2011 


References are contained in <xref type="rfc" data="rfc4355"/>. 


</paragraph> 
</functionalspec> 
<security> 
<paragraph> 
There are no specific security issues with this 


Enumservice. However, the general considerations of 
Section 6 of <xref type="rfc" data="rfc4355"/> apply. 


</paragraph> 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 


<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 


<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
</record> 
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4.19. sms:tel 


<record> 
<!-- sms:tel --> 
<class>Application-Based, Common</class> 
<type>sms</type> 
<subtype>tel</subtype> 
<urischeme>tel</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of receiving a message using the Short Message 
Service (SMS) [14]. 
</paragraph> 
<paragraph> 


March 2011 


References are contained in <xref type="rfc" data="rfc4355"/>. 


</paragraph> 
</functionalspec> 
<security> 
<paragraph> 
There are no specific security issues with this 


Enumservice. However, the general considerations of 


Section 6 of <xref type="rfc" data="rfc4355"/> apply. 


</paragraph> 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 


<xref type="rfc" data="rfc4355"/> (updated by RFC 6118) 


<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
</record> 
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4.20. unifmsg:http 


<record> 
<!-- unifmsg:http --> 
<class>Application-Based, Common</class> 
<type>unifmsg</type> 
<subtype>http</subtype> 
<urischeme>http</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified by 
the associated URI scheme is capable of being a source of 
information. 
</paragraph> 
<paragraph> 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'http:” [11] URI 
provides a document. This document can contain references 
that will trigger the download of many different kinds of 
information, such as text, audio, video, executable code, or 
even video message files. Thus, one cannot be more specific 
about the kind of information expected when contacting the 
resource. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.21. unifmsg:https 


<record> 
<!-- unifmsg:https --> 
<class>Application-Based, Common</class> 
<type>unifmsg</type> 
<subtype>https</subtype> 
<urischeme>https</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified by 
the associated URI scheme is capable of being a source of 
information, which can be contacted using TLS or the Secure 
Socket Layer protocol. 
</paragraph> 
<paragraph> 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'https:” [12] URI 
provides a document. This document can contain references 
that will trigger the download of many different kinds of 
information, such as text, audio, video, executable code, or 
even video message files. Thus, one cannot be more specific 
about the kind of information expected when contacting the 
resource. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.22. unifmsg:sip 


<record> 
<!-- unifmsg:sip --> 
<class>Application-Based, Common</class> 
<type>unifmsg</type> 
<subtype>sip</subtype> 
<urischeme>sip</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified can 
be addressed by the associated URI scheme in order to 
initiate a unified communication session to a unified 
messaging system. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.23. unifmsg:sips 


<record> 
<!-- unifmsg:sips --> 
<class>Application-Based, Common</class> 
<type>unifmsg</type> 
<subtype>sips</subtype> 
<urischeme>sips</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified can 
be addressed by the associated URI scheme in order to 
initiate a unified communication session to a unified 
messaging system. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 


Hoeneisen & Mayrhofer Standards Track [Page 28] 


RFC 6118 Update Legacy Enumservice Registrations March 2011 


4.24. vcard 


<record> 
<!-- vcard --> 
<class>Data Type-Based</class> 
<type>vcard</type> 
<!-- No subtype --> 
<urischeme>http</urischeme> 
<urischeme>https</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified is a plain vCard, according to RFC2426, 
which may be accessed using HTTP / HTTPS [7]. 
</paragraph> 
<paragraph> 
Clients fetching the vCard from the resource 
indicated should expect access to be 
restricted. Additionally, the comprehension of the 
data provided may vary depending on the client’s 
identity. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc4969"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4969"/>, Section 5. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4969"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Alexander_Mayrhofer"/> 
</requesters> 
</record> 
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4.25. videomsg:http 


<record> 
<!-- videomsg:http --> 
<class>Application-Based, Common</class> 
<type>videomsg</type> 
<subtype>http</subtype> 
<urischeme>http</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified by 
the associated URI scheme is capable of being a source of 
information. 
</paragraph> 
<paragraph> 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'http:” [11] URI 
provides a document. This document can contain references 
that will trigger the download of many different kinds of 
information, such as text, audio, video, executable code, or 
even video message files. Thus, one cannot be more specific 
about the kind of information expected when contacting the 
resource. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.26. videomsg:https 


<record> 
<!-- videomsg:https --> 
<class>Application-Based, Common</class> 
<type>videomsg</type> 
<subtype>https</subtype> 
<urischeme>https</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified by 
the associated URI scheme is capable of being a source of 
information, which can be contacted using TLS or the Secure 
Socket Layer protocol. 
</paragraph> 
<paragraph> 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'https:” [12] URI 
provides a document. This document can contain references 
that will trigger the download of many different kinds of 
information, such as text, audio, video, executable code, or 
even video message files. Thus, one cannot be more specific 
about the kind of information expected when contacting the 
resource. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.27. videomsg:sip 


<record> 
<!-- videomsg:sip --> 
<class>Application-Based, Common</class> 
<type>videomsg</type> 
<subtype>sip</subtype> 
<urischeme>sip</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified can 
be addressed by the associated URI scheme in order to 
initiate a video communication session to a video messaging 
system. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.28. videomsg:sips 


<record> 
<!-- videomsg:sips --> 
<class>Application-Based, Common</class> 
<type>videomsg</type> 
<subtype>sips</subtype> 
<urischeme>sips</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified can 
be addressed by the associated URI scheme in order to 
initiate a video communication session to a video messaging 
system. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.29. voice:tel 


<record> 
<!-- voice:tel --> 
<class>Application-Based, Common</class> 
<type>voice</type> 
<subtype>tel</subtype> 
<urischeme>tel</urischeme> 


<functionalspec> 
<paragraph> 
The kind of communication indicated by this 
Enumservice is "Interactive Voice". From a protocol 


perspective, this communication is expected to 
involve bidirectional media streams carrying audio 
data. 
</paragraph> 
<paragraph> 
A client may imply that the person controlling 
population of a NAPTR holding this Enumservice 
indicates their capability to engage in an 
interactive voice session when contacted using the 
URI generated by this NAPTR. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4415"/>, Section 5. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4415"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
This Enumservice indicates that the person 
responsible for the NAPTR is accessible via the PSTN 
(Public Switched Telephone Network) or PLMN (Public 
Land Mobile Network) using the value of the 
generated URI. 
</paragraph> 
<paragraph>The kind of subsystem required to initiate a 
Voice Enumservice with this Subtype is a "Dialler". 
This is a subsystem that either provides a local 
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connection to the PSTN or PLMN, or that provides an 
indirect connection to those networks. The 
subsystem will use the telephone number held in the 
generated URI to place a voice call. The voice call 
is placed to a network that uses E.164 numbers to 
route calls to an appropriate destination. 


</paragraph> 

<paragraph> 
Note that the PSTN/PLMN connection may be 
indirect. The end user receiving this NAPTR may 


have a relationship with a Communications Service 
Provider that accepts call initiation requests from 
that subsystem using an IP-based protocol such as 
SIP or H.323, and places the call to the PSTN using 


a remote gateway service. In this case, the Provider 
may either accept requests using "tel:" URIs or has 
a defined mechanism to convert "tel:" URI values 
into a "protocol-native" form. 
</paragraph> 
<paragraph> 


The "tel:" URI value SHOULD be fully qualified 
(using the "global phone number" form of RFC 3966 
[101). A "local phone number" as defined in that 
document SHOULD NOT be used unless the controller of 
the zone in which the NAPTR appears is sure that it 
Can be distinguished unambiguously by all clients 
that can access the resource record and that a call 
from their network access points can be routed to 
that destination. 

</paragraph> 

<paragraph> 
References are contained in <xref type="rfc" data="rfc4415"/>. 

</paragraph> 

</additionalinfo> 
</record> 
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4.30. voicemsg:http 


<record> 
<!-- voicemsg:http --> 
<class>Application-Based, Common</class> 
<type>voicemsg</type> 
<subtype>http</subtype> 
<urischeme>http</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified by 
the associated URI scheme is capable of being a source of 
information. 
</paragraph> 
<paragraph> 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'http:” [11] URI 
provides a document. This document can contain references 
that will trigger the download of many different kinds of 
information, such as text, audio, video, executable code, or 
even voice message files. Thus, one cannot be more specific 
about the kind of information expected when contacting the 
resource. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.31. voicemsg:https 


<record> 
<!-- voicemsg:https --> 
<class>Application-Based, Common</class> 
<type>voicemsg</type> 
<subtype>https</subtype> 
<urischeme>https</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified by 
the associated URI scheme is capable of being a source of 
information, which can be contacted using TLS or the Secure 
Socket Layer protocol. 
</paragraph> 
<paragraph> 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an ’https:’ [12] URI 
provides a document. This document can contain references 
that will trigger the download of many different kinds of 
information, such as text, audio, video, executable code, or 
even voice message files. Thus, one cannot be more specific 
about the kind of information expected when contacting the 
resource. 
</paragraph> 
<paragraph> 
References are contained in <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.32. voicemsg:sip 


<record> 
<!-- voicemsg:sip --> 
<class>Application-Based, Common</class> 
<type>voicemsg</type> 
<subtype>sip</subtype> 
<urischeme>sip</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified can 
be addressed by the associated URI scheme in order to 
initiate a voice communication session to a voice messaging 
system. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.33. voicemsg:sips 


<record> 
<!-- voicemsg:sips --> 
<class>Application-Based, Common</class> 
<type>voicemsg</type> 
<subtype>sips</subtype> 
<urischeme>sips</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified can 
be addressed by the associated URI scheme in order to 
initiate a voice communication session to a voice messaging 
system. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.34. voicemsg:tel 


<record> 
<!-- voicemsg:tel --> 
<class>Application-Based, Common</class> 
<type>voicemsg</type> 
<subtype>tel</subtype> 
<urischeme>tel</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource identified can 
be addressed by the associated URI scheme in order to 
initiate a voice communication session to a voice messaging 
system. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc5278"/>, Section 3. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc5278"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Jason_Livingood"/> 
<xref type="person" data="Don_Troshynski"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Implementers should review a non-exclusive list of examples 
in Section 7 of <xref type="rfc" data="rfc5278"/>. 
</paragraph> 
</additionalinfo> 
</record> 
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4.35. vpim:ldap 


<record> 
<!-- vpim:ldap --> 
<class>Data Type-Based</class> 
<type>vpim</type> 
<subtype>1dap</subtype> 
<urischeme>ldap</urischeme> 
<functionalspec> 
See <xref type="rfc" data="rfc4238"/>, Section 3.2 - 3.3. 
</functionalspec> 
<security> 
<paragraph> 
Malicious Redirection: 
One of the fundamental dangers related to any 
service such as this is that a malicious entry ina 
resolver’s database will cause clients to resolve 
the E.164 into the wrong LDAP URI. The possible 
intent may be to cause the client to connect to a 
rogue LDAP server and retrieve (or fail to retrieve) 
a resource containing fraudulent or damaging 
information. 
</paragraph> 
<paragraph> 
Denial of Service: 
By removing the URI to which the E.164 maps, a 
malicious intruder may remove the client’s ability 
to access the LDAP directory server. 
</paragraph> 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4238"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Greg_Vaudreuil"/> 
</requesters> 
</record> 
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4.36. vpim:mailto 


<record> 
<!-- vpim:mailto --> 
<class>Data Type-Based</class> 
<type>vpim</type> 


<subtype>mailto</subtype> 
<urischeme>mailto</urischeme> 
<functionalspec> 
See <xref type="rfc" data="rfc4238"/>, Section 4.2 - 4.4. 
</functionalspec> 
<security> 
<paragraph> 
Malicious Redirection: 
One of the fundamental dangers related to any 
service such as this is that a malicious entry in a 
resolver’s database will cause clients to resolve 
the E.164 into the wrong email URI. The possible 
intent may be to cause the client to send the 
information to an incorrect destination. 
</paragraph> 
<paragraph> 
Denial of Service: 
By removing the URI to which the E.164 maps, a 
malicious intruder may remove the client’s ability 
to access the resource. 
</paragraph> 
<paragraph> 
Unsolicited Bulk Email: 
The exposure of email addresses through the ENUM 
service provides a bulk mailer access to large 
numbers of email addresses where only the telephone 
number was previously known. 
</paragraph> 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4238"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Greg_Vaudreuil"/> 
</requesters> 
<additionalinfo> 
<paragraph> 
Error Conditions: 
</paragraph> 
<paragraph> 
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E.164 number not in 
</paragraph> 
<paragraph> 

E.164 number in the 

URIs exist for that 
</paragraph> 
<paragraph> 
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the numbering plan 


numbering plan, but no 
number 


E2U+vpim:mailto Service unavailable of email 
addresses where only the telephone number was 


previously known. 
</paragraph> 
</additionalinfo> 
</record> 
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4. 


31% 


web:http 


<record> 


<!-- web:http --> 
<class>Application-Based, Common</class> 
<type>web</type> 
<subtype>http</subtype> 
<urischeme>http</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified by the associated URI is capable 
of being a source of information. It has to be 
noted that the kind of information retrieved can be 
manifold. Usually, contacting a resource by an 
"http:" URI provides a document. This document can 
contain references that will trigger download of 
many different kinds of information, like audio or 
video or executable code. Thus, one cannot be more 
specific about the kind of information that can be 
expected when contacting the resource. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4002"/>, Section 5. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4002"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 
</requesters> 


</record> 
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4.38. web:https 


<record> 

<!-- web:https --> 

<class>Application-Based, Common</class> 

<type>web</type> 

<subtype>https</subtype> 

<urischeme>https</urischeme> 

<functionalspec> 

<paragraph> 

This Enumservice indicates that the resource 
identified by the associated URI is capable 
of being a source of information, which can be 
contacted by using TLS or the Secure Socket Layer 
protocol. It has to be noted that the kind of 
information retrieved can be manifold. Usually, 


contacting a resource by an "https:" URI provides a 
document. This document can contain all different 
kinds of information, like audio or video or 
executable code. Thus, one cannot be more specific 
what information to expect when contacting the 
resource. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4002"/>, Section 5. 
</security> 


<usage>COMMON</usage> 

<registrationdocs> 
<xref type="rfc" data="rfc4002"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 

</registrationdocs> 

<requesters> 
<xref type="person" data="Rudolf_Brandner"/> 
<xref type="person" data="Lawrence_Conroy"/> 
<xref type="person" data="Richard_Stastny"/> 

</requesters> 

</record> 
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4. 


Die 


39. xmpp 


<record> 
<!-- xmpp --> 
<class>Protocol-Based</class> 
<type>xmpp</type> 
<!-- No subtype --> 
<urischeme>xmpp</urischeme> 
<functionalspec> 
<paragraph> 
This Enumservice indicates that the resource 
identified is an XMPP entity. 
</paragraph> 
</functionalspec> 
<security> 
See <xref type="rfc" data="rfc4979"/>, Section 6. 
</security> 
<usage>COMMON</usage> 
<registrationdocs> 
<xref type="rfc" data="rfc4979"/> (updated by RFC 6118) 
<xref type="rfc" data="RFC 6118"/> 
</registrationdocs> 
<requesters> 
<xref type="person" data="Alexander_Mayrhofer"/> 
</requesters> 
</record> 


IANA Considerations 

IANA replaced all legacy Enumservice Registrations as per Section 4. 
Security Considerations 

Since this document does not introduce any technology or protocol, 
there are no security issues to be considered for this document 
itself. 
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Appendix A. Former Content of the IANA Repository 
Enumservice Registrations 
(last updated 2009-10-13) 


Registries included below: 
- Enumservice Registrations 


Registry Name: Enumservice Registrations 
Reference: [RFC3761] 
Registration Procedures: Require an RFC approved by the IESG 


Note: 

Enumservice specifications contain the functional specification (i.e. 
what it can be used for), the valid protocols, and the URI schemes 
that may be returned. 


Registry: 
Service Name: "H323" 
URI Scheme (s): "h323:" 


Functional Specification: 

See Section "3. The E2U+H323 ENUM Service" of [RFC3762] 
Security considerations: 

see section "5. Security Considerations" of [RFC3762] 
Intended usage: COMMON 
Author: Orit Levin 
[RFC3762] 


Service Name: "SIP" 
Type(s): "SIP" 
Subtype (s): N/A 
URI Scheme (s): "sip", "sips:" 
Functional Specification: see Section 4 of [RFC3764] 
Security considerations: see Section 6 of [RFC3764] 
Intended usage: COMMON 
Author: Jon Peterson (jon.peterson&neustar.biz) 
Any other information that the author deems interesting: 
see Section 3 of [RFC3764] 
[RFC3764] 
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Service Name: "ifax" 
Type: "ifax" 
Subtype: "mailto" 
URI Scheme: "mailto" 


The URI Scheme is "mailto" because facsimile is a profile of 


standard Internet mail and uses standard Internet mail 
addressing. 
Functional Specification: see section 1 of [RFC4143] 
Security Considerations: see section 3 of [RFC4143] 
Intended usage: COMMON 
Author: Kiyoshi Toyoda (toyoda.kiyoshi&jp.panasonic.com) 
Dave Crocker (dcrockergbrandenburg.com) 
[RFC4143] 


Service Name: "pres" 
URI Scheme (s): "pres:" 
Functional Specification: see Section 4 of [RFC3953] 
Security considerations: see Section 6 of [RFC3953] 
Intended usage: COMMON 
Author: Jon Peterson (jon.peterson&neustar.biz) 
Any other information that the author deems interesting: 
See Section 3 of [RFC3953] 
[RFC3953] 


Service Name: "web" 
Type: "web" 
Subtype: "http" 
URI Scheme: 'http:” 
Functional Specification: 


This ENUMservice indicates that the resource identified by the 


associated URI scheme is capable of being a source of 


information. It has to be noted that the kind of information 
retrieved can be manifold. Usually, contacting a resource by an 
‘http:’ URI provides a document. This document can contain 
references that will trigger download of many different kinds 


of information, like audio or video or executable code. 


Thus, 


one Can not be more specific about the kind of information that 


Can be expected when contacting the resource. 
Security Considerations: 
See section 5 of [RFC4002]. 
Intended Usage: COMMON 
Authors: 
Rudolf Brandner (rudolf.brandner&siemens.com) 
Lawrence Conroy (lwc&roke.co.uk) 
Richard Stastny (richard.stastny&oefeg.at) 
Any other information the author deems interesting: None 
[RFC4002] 
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Service Name: "web" 

Type: "web" 

Subtype: "https" 

URI Scheme: ’https:’ 

Functional Specification: 
This ENUMservice indicates that the resource identified by the 
associated URI scheme is capable of being a source of 
information, which can be contacted by using TLS or Secure 
Socket Layer protocol. It has to be noted that the kind of 
information retrieved can be manifold. Usually, contacting a 
resource by an 'https:” URI provides a document. This document 
can contain all different kind of information, like audio or 
video or executable code. Thus, one can not be more specific 
what information to expect when contacting the resource. 

Security Considerations: 
See section 5 of [RFC4002]. 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner (rudolf.brandner&siemens.com) 
Lawrence Conroy (lwc&roke.co.uk) 
Richard Stastny (richard.stastny&oefeg.at) 

Any other information the author deems interesting: None 

[RFC4002] 


Service Name: "ft" 
Type: "ft" 
Subtype: "ftp" 
URI Scheme: ’ftp:’ 
Functional Specification: 
This ENUMservice indicates that the resource identified by the 
associated URI scheme is a file service from which a file or 
file listing can be retrieved. 
Security Considerations: 
See section 5 of [RFC4002]. 
Intended Usage: COMMON 
Authors: 
Rudolf Brandner (rudolf.brandner&siemens.com) 
Lawrence Conroy (lwc&roke.co.uk) 
Richard Stastny (richard.stastny&oefeg.at) 
Any other information the author deems interesting: None 
[RFC4002] 
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Enumservice Name: "email" 

Enumservice Type: "email" 

Enumservice Subtype: "mailto" 

URI Scheme: 'mailto:” 

Functional Specification: 
This Enumservice indicates that the remote resource can be 
addressed by the associated URI scheme in order to send an 
email. 

Security Considerations: 
See Section 6 of [RFC4355] 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
None 


Enumservice Name: "fax" 

Enumservice Type: "fax" 

Enumservice Subtype: "tel" 

URI Scheme: ‘’tel:’ 

Functional Specification: 
This Enumservice indicates that the resource identified by the 
associated URI scheme is capable of being contacted to provide 
a communication session during which facsimile documents can be 
sent. 
A client selecting this NAPTR will have support for generating 
and sending facsimile documents to the recipient using the PSTN 
session and transfer protocols specified in [12] and [13] in 
[RFC4355] - in short, they will have a fax 
program with a local or shared PSTN access over which they can 
send faxes. 

Security Considerations: 
See Section 6 of [RFC4355] 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
None 
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Enumservice Name: "sms" 


Enumservice Type: "sms" 

Enumservice Subtypes: "tel" 

URI Scheme: ‘’tel:’ 

Functional Specification: 
This Enumservice indicates that the resource identified by the 
associated URI scheme is capable of receiving a message using 
the Short Message Service (SMS) [14] in [RFC4355]. 

Security Considerations: 
There are no specific security issues with this Enumservice. 
However, the general considerations of Section 6 apply. 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
None 


Enumservice Name: "sms" 


Enumservice Type: "sms" 

Enumservice Subtypes: "mailto" 

URI Scheme: 'mailto:” 

Functional Specification: 
This Enumservice indicates that the resource identified by the 
associated URI scheme is capable of receiving a message using 
an email protocol. 
SMS content is sent over SMTP using the format specified by TS 
23.140 [15] section 8.4.4 and TS 26.140 [16] section 4 (for 
references see [RFC4355]), as an MMS message. Within such a 
message, SMS content is carried as either a text or 
application/octet-stream MIME sub-part (see TS 26.140 [16] , 
section 4.1) 
For references see [RFC4355]. 

Security Considerations: 
There are no specific security issues with this Enumservice. 
However, the general considerations of Section 6 apply, see 
[RFC4355]. 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
None 
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Enumservice Name: "ems" 

Enumservice Type: "ems" 

Enumservice Subtype: "tel" 

URI Scheme: ‘’tel:’ 

Functional Specification: 
This Enumservice indicates that the resource identified by the 
associated URI scheme is capable of receiving a message using 
the Enhanced Message Service (EMS) [14] (For reference see 
[RFC4355]). 

Security Considerations: 
There are no specific security issues with this Enumservice. 
However, the general considerations of Section 6 apply. 
See [RFC4355] 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
Note that an indication of EMS can be taken as implying that 
the recipient is capable of receiving SMS messages at this 
address as well. 


Enumservice Name: "ems" 

Enumservice Type: "ems" 

Enumservice Subtypes: "mailto" 

URI Scheme: ’mailto:’ 

Functional Specification: 
This Enumservice indicates that the resource identified by the 
associated URI scheme is capable of receiving a message using 
an email protocol. 
EMS content is sent over SMTP using the format specified by TS 
23.140 [15] section 8.4.4 and TS 26.140 [16] section 4, as an 
MMS message. Within such a message, EMS content is carried as 
either a text or application/octet-stream MIME sub-part (see 
TS 26.140 [16] , section 4.1). 
For references see [RFC4355] 

Security Considerations: 
There are no specific security issues with this Enumservice. 
However, the general considerations of Section 6 of [RFC4355] 
apply. 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
None 
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Enumservice Name: "mms" 

Enumservice Type: "mms" 

Enumservice Subtype: "tel" 

URI Scheme: ‘’tel:’ 

Functional Specification: 
This Enumservice indicates that the resource identified by the 
associated URI scheme is capable of receiving a message using 
the Multimedia Messaging Service (MMS) [15]. 
For references see [RFC4355] 

Security Considerations: 
There are no specific security issues with this Enumservice. 
However, the general considerations of Section 6 of [RFC4355] 
apply. 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
Note that MMS can be used as an alternative to deliver an SMS 
RP-DATA RPDU if, for example, the SMS bearer is not supported. 
If an entry includes this Enumservice, then in effect this can 
be taken as implying that the recipient is capable of receiving 
EMS or SMS messages at this address. Such choices on the end 
system design do have two small caveats; whilst in practice all 
terminals supporting MMS today support SMS as well, it might 
not necessarily be the case in the future, and there may be 
tariff differences in using the MMS rather than using the SMS 
or EMS. 


Enumservice Name: "mms" 

Enumservice Type: "mms" 

Enumservice Subtypes: "mailto" 

URI Scheme: 'mailto:” 

Functional Specification: 
This Enumservice indicates that the resource identified by the 
associated URI scheme is capable of receiving a message using 
an email protocol. 
MMS messages are sent over SMTP using the format specified by 
TS 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4. 
Within and between MMS Environments (MMSE, network 
infrastructures that support the MultiMedia Service), other 
pieces of state data (for example, charging-significant 
information) are exchanged between MMS Relay Servers. Thus, 
although these servers use SMTP as the "bearer" for their 
application exchanges, they map their internal state to 
specialised headers carried in the SMTP message exchanges. 
The headers used in such MMSE are described in detail in [17]. 
For references see [RFC4355] 
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Security Considerations: 
There are no specific security issues with this Enumservice. 
However, the general considerations of Section 6 of [RFC4355] 
apply. 

Intended Usage: COMMON 

Authors: 
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author 
contact detail see [RFC4355]) 

Any other information the author deems interesting: 
The MMS Architecture describes an interface between the MMSE and 
"legacy messaging systems" (labelled as MM3) which accepts 
"standard" SMTP messages. Thus although the MMS Relay Server 
that supports this interface appears as a standard SMTP server 
from the perspective of an Internet-based mail server, it acts 
as a gateway and translator, adding the internal state data that 
is used within and between the MMS Environments. This mechanism 
is described in [17], which also includes references to the 
specifications agreed by those bodies responsible for the design 
of the MMS. 


Service Name: E.164 to VPIM MailTo: URL 
URI Type: "Mailto:" 
Type: VPIM 
Subtype: MAILTO 
Functional Specification: See section 4.2 through 4.4 of [RFC4238] 
Intended Usage: COMMON 
Author: Greg Vaudreuil (gregv&ieee.org) 
Error Conditions: 
o E.164 number not in the numbering plan 
o E.164 number in the numbering plan, but no URLs exist for that 
number 
o E2U+VPIM:Mailto Service unavailable 
Security Considerations: 
o Malicious Redirection 
One of the fundamental dangers related to any service such as 
this is that a malicious entry in a resolver’s database will 
cause clients to resolve the E.164 into the wrong email URL. 
The possible intent may be to cause the client to send the 
information to an incorrect destination. 
o Denial of Service 
By removing the URL to which the E.164 maps, a malicious 
intruder may remove the client’s ability to access the 
resource. 
o Unsolicited Bulk Email 
The exposure of email addresses through the ENUM 
service provides a bulk mailer access to large numbers 
of email addresses where only the telephone number was 
previously known. 
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Service Name: E.164 to VPIM LDAP URL 

URI Type: "LDAP:" 

Type: VPIM 

Subtype: LDAP 

Functional Specification: See section 3.2 through 3.3 of [RFC4238] 

Intended Usage: COMMON 

Author: Greg Vaudreuil (gregv&ieee.org) 

Security Considerations: 

o Malicious Redirection 
One of the fundamental dangers related to any service 
such as this is that a malicious entry in a resolver’s 
database will cause clients to resolve the E.164 into 
the wrong LDAP URL. The possible intent may be to cause 
the client to connect to a rogue LDAP server and 
retrieve (or fail to retrieve) a resource containing 
fraudulent or damaging information. 
o Denial of Service 

By removing the URL to which the E.164 maps, a 
malicious intruder may remove the client’s ability to 
access the LDAP directory server. 


Enumservice Name: "voice" 
Enumservice Type: "voice" 

Enumservice Subtype: "tel" 

URI Scheme: 'tel:” 

Functional Specification: 
The kind of communication indicated by this Enumservice is 
"Interactive Voice". From a protocol perspective, this 
communication is expected to involve bidirectional media streams 
carrying audio data. 
A client may imply that the person controlling population of a 
NAPTR holding this Enumservice indicates their capability to 
engage in an interactive voice session when contacted using the 
URI generated by this NAPTR. 

Security Considerations: 
See Section 5 of [RFC4415] 

Intended Usage: COMMON 

Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for 

author contact detail see Authors’ Addresses section) 

Any other information the author deems interesting: 

o This Enumservice indicates that the person responsible for the 
NAPTR is accessible via the PSTN (Public Switched Telephone 
Network) or PLMN (Public Land Mobile Network) using the value of 
the generated URI. 

o The kind of subsystem required to initiate a Voice Enumservice 
with this sub-type is a "Dialler". This is a subsystem that 
either provides a local connection to the PSTN or PLMN, or that 
provides an indirect connection to those networks. The 
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subsystem will use the telephone number held in the generated 


URI to place a voice call. The voice call is placed to a 
network that uses E.164 numbers to route calls to an appropriate 
destination. 


o Note that the PSTN/PLMN connection may be indirect. The end 
user receiving this NAPTR may have a relationship with a 
Communications Service Provider that accepts call initiation 
requests from that subsystem using an IP-based protocol such as 
SIP or H.323, and places the call to the PSTN using a remote 
gateway service. In this case the Provider may either accept 
requests using "tel:" URIs or has a defined mechanism to convert 
"tel:" URI values into a "protocol-native" form. 

o The "tel:" URI value SHOULD be fully qualified (using the 
"global phone number" form of RFC3966 [10]). A "local phone 
number" as defined in that document SHOULD NOT be used unless 
the controller of the zone in which the NAPTR appears is sure 
that it can be distinguished unambiguously by all clients that 
can access the resource record and that a call from their 
network access points can be routed to that destination. 


Enumservice Name: "pstn" 

Enumservice Type: "pstn" 

Enumservice Subtype: "tel" 

URI Scheme: 'tel:” 

Functional Specification: 
These Enumservices indicate that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a telecommunication session, which may include two-way 
voice or other communications, to the PSTN. These URIs may 
contain number portability data as specified in RFC 4694 [10]. 

Security Considerations: See Section 7 of [RFC4769]. 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Richard Shockey (richard.shockey&neustar.biz) 

Any other information the author deems interesting: 
A Number Portability Dip Indicator (npdi) should be used in 
practice (see examples below in Section 4 of [RFC4769]). 
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Enumservice Name: "pstn" 
Enumservice Type: "pstn" 
Enumservice Subtype: "sip" 


URI Scheme: ’sip:’ 

Functional Specification: 
These Enumservices indicate that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a telecommunication session, which may include two-way 
voice or other communications, to the PSTN. 

Security Considerations: See Section 7 of [RFC4769]. 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Richard Shockey (richard.shockey&neustar.biz) 

Any other information the author deems interesting: 
A Number Portability Dip Indicator (npdi) should be used in 
practice (see examples below in Section 4 of [RFC4769]). 


Enumservice Name: "vCard" 
Enumservice Name: "vCard" 
Enumservice Type: "vcard" 


Enumservice Subtype: n/a 

URI Schemes: "http", "https" 

Functional Specification: 
This Enumservice indicates that the resource identified is a 
plain vCard, according to RFC 2426, which may be accessed using 
HTTP/ HTTPS [7]. 
Clients fetching the vCard from the resource indicated should 
expect access to be restricted. Additionally, the comprehension 
of the data provided may vary depending on the client’s 
identity. 

Security Considerations: see Section 5 [RFC4969] 

Intended Usage: COMMON 

Author: Alexander Mayrhofer <alexander.mayrhoferéenum.at> 


Enumservice Name: "XMPP" 

Enumservice Type: "xmpp" 

Enumservice Subtype: n/a 

URI Schemes: "xmpp" 

Functional Specification: 
This Enumservice indicates that the resource identified is an 
XMPP entity. 

Security Considerations: see Section 6 of [RFC4979] 

Intended Usage: COMMON 

Author: Alexander Mayrhofer <alexander.mayrhoferéenum.at> 
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Enumservice Name: "im" 

Enumservice Type: "im" 

Enumservice Subtypes: N/A 

URI scheme(s): "im:" 

Functional Specification: 
This Enumservice indicates that the resource identified 
is an ’im:’ URI. The ’im:’ URI scheme does not identify 
any particular protocol that will be used to handle 
instant messaging receipt or delivery, rather the mechanism 
in RFC 3861 [4] is used to discover whether an IM protocol 
supported by the party querying ENUM is also supported by 
the target resource. 

Security considerations: See section 3 of [RFC5028] 

Intended usage: COMMON 

Author: Rohan Mahy (rohangekabal.com) 


Enumservice Name: "voicemsg" 

Enumservice Type: "voicemsg" 

Enumservice Subtypes: "sip" 

URI Schemes: ’sip:’ 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a voice communication session to a voice messaging 
system. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "voicemsg" 

Enumservice Type: "voicemsg" 

Enumservice Subtypes: "sips" 

URI Schemes: 'sips:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a voice communication session to a voice messaging 
system. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynski&acmepacket .com) 
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Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "voicemsg" 

Enumservice Type: "voicemsg" 

Enumservice Subtype: "tel" 

URI Schemes: 'tel:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a voice communication session to a voice messaging 
system. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "voicemsg" 

Enumservice Type: "voicemsg" 

Enumservice Subtype: "http" 

URI Schemes: ’http:’ 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
by the associated URI scheme is capable of being a source of 
information. 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'http:” [11] URI provides a 
document. This document can contain references that will trigger 
the download of many different kinds of information, such as 
text, audio, video, executable code, or even voice message 
files. Thus, one cannot be more specific about the kind of 
information expected when contacting the resource. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 
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Enumservice Name: "voicemsg" 

Enumservice Type: "voicemsg" 

Enumservice Subtype: "https" 

URI Schemes: 'https:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
by the associated URI scheme is capable of being a source of 
information, which can be contacted using TLS or the Secure 
Socket Layer protocol. 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'https:” [12] URI provides 
a document. This document can contain references that will 
trigger the download of many different kinds of information, 
such as text, audio, video, executable code, or even voice 
message files. Thus, one cannot be more specific about the kind 
of information expected when contacting the resource. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "videomsg" 
Enumservice Type: "videomsg" 

Enumservice Subtypes: "sip" 

URI Schemes: 'sip:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a video communication session to a video messaging 
system. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 
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Enumservice Name: "videomsg" 

Enumservice Type: "videomsg" 

Enumservice Subtypes: "sips" 

URI Schemes: 'sips:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a video communication session to a video messaging 
system. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "videomsg" 

Enumservice Type: "videomsg" 

Enumservice Subtype: "http" 

URI Schemes: ’http:’ 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
by the associated URI scheme is capable of being a source of 
information. 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'http:” [11] URI provides a 
document. This document can contain references that will trigger 
the download of many different kinds of information, such as 
text, audio, video, executable code, or even video message 
files. Thus, one cannot be more specific about the kind of 
information expected when contacting the resource. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynski&acmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 
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Enumservice Name: "videomsg" 

Enumservice Type: "videomsg" 

Enumservice Subtype: "https" 

URI Schemes: 'https:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
by the associated URI scheme is capable of being a source of 
information, which can be contacted using TLS or the Secure 
Socket Layer protocol. 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'https:” [12] URI provides 
a document. This document can contain references that will 
trigger the download of many different kinds of information, 
such as text, audio, video, executable code, or even video 
message files. Thus, one cannot be more specific about the kind 
of information expected when contacting the resource. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynski&acmepacket .com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "unifmsg" 
Enumservice Type: "unifmsg" 

Enumservice Subtypes: "sip" 

URI Schemes: ’sip:’ 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a unified communication session to a unified messaging 
system. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 
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Enumservice Name: "unifmsg" 

Enumservice Type: "unifmsg" 

Enumservice Subtypes: "sips" 

URI Schemes: 'sips:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
can be addressed by the associated URI scheme in order to 
initiate a unified communication session to a unified messaging 
system. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "unifmsg" 

Enumservice Type: "unifmsg" 

Enumservice Subtype: "http" 

URI Schemes: ’http:’ 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
by the associated URI scheme is capable of being a source of 
information. 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'http:” [11] URI provides a 
document. This document can contain references that will trigger 
the download of many different kinds of information, such as 
text, audio, video, executable code, or even video message 
files. Thus, one cannot be more specific about the kind of 
information expected when contacting the resource. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynskisacmepacket.com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 
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Enumservice Name: "unifmsg" 

Enumservice Type: "unifmsg" 

Enumservice Subtype: "https" 

URI Schemes: 'https:” 

Functional Specification: 
This Enumservice indicates that the remote resource identified 
by the associated URI scheme is capable of being a source of 
information, which can be contacted using TLS or the Secure 
Socket Layer protocol. 
Note that the kind of information retrieved can be manifold. 
Usually, contacting a resource by an 'https:” [12] URI provides 
a document. This document can contain references that will 
trigger the download of many different kinds of information, 
such as text, audio, video, executable code, or even video 
message files. Thus, one cannot be more specific about the kind 
of information expected when contacting the resource. 

Security Considerations: See Section 3 of [RFC5278] 

Intended Usage: COMMON 

Authors: 
Jason Livingood (jason_livingood&cable.comcast.com) 
Don Troshynski (dtroshynski&acmepacket .com) 

Any other information the author deems interesting: 
Implementers should review a non-exclusive list of examples 
below in Section 7 of [RFC5278] 


Enumservice Name: "ical-sched" 
Enumservice Type: "ical-sched" 

Enumservice Subtypes: "mailto" 

URI scheme(s): ’mailto:’ 

Functional Specification: 
This Enumservice indicates that the resource identified can be 
addressed by the associated URI used for scheduling using 
Internet calendaring via Internet mail with the iMIP [6] 
protocol. 

Security considerations: See Section 4 of [RFC5333]. 

Intended usage: COMMON 

Author: 
Rohan Mahy (rohangekabal.com) 
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Enumservice Name: "ical-access" 

Enumservice Type: "ical-access" 

Enumservice Subtypes: "http" 

URI scheme (s): “http:” 

Functional Specification: 
This Enumservice indicates that the resource identified can be 
addressed by the associated URI in order to access a user's 
calendar (for example free/busy status) using the CalDAV [7] 
protocol for Internet calendaring. 

Security considerations: See Section 4 of [RFC5333]. 

Intended usage: COMMON 

Author: 
Rohan Mahy (rohangekabal.com) 


Enumservice Name: "ical-access" 

Enumservice Type: "ical-access" 

Enumservice Subtypes: "https" 

URI scheme (s): ‘’https:’ 

Functional Specification: 
This Enumservice indicates that the resource identified can be 
addressed by the associated URI in order to access a user's 
calendar (for example free/busy status) using the CalDAV [7] 
protocol for Internet calendaring. 

Security considerations: See Section 4 of [RFC5333]. 

Intended usage: COMMON 

Author: 
Rohan Mahy (rohangekabal.com) 
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